1. Field of the Invention
The present invention relates to a communication apparatus for authenticating another communication apparatus by using a digital certificate, a communication system having the communication apparatus serving as an upper level apparatus and the other communication apparatus serving as a lower level apparatus, a certificate transmission method for transmitting a digital certificate to be used in authentication with the communication apparatuses and the communication system, and a program for enabling a computer to function as the communication apparatus.
2. Description of the Related Art
In the past recent years and continuing, various systems, having numerous communication apparatuses communicating through a network, are being constructed. One example is the so-called e-commerce system which employs a communication server apparatus for receiving orders through the Internet. In another exemplary system, various electronic apparatuses serving as a client apparatus or a server apparatus are connected via a network for enabling remote management of the electronic apparatuses by communicating with each other.
Confirming whether the communication opponent is authentic and/or whether the transmitted information has been tampered with is necessary in constructing such systems. Particularly, in a case of transmitting confidential information through the Internet where information is liable to be transferred to an unauthorized opponent, it is also necessary to prevent others from viewing (stealing) the content of the confidential information. As one example, SSL (Secure Socket Layer) is a well-known communication protocol that is developed for satisfying the above-described necessities. This protocol authenticates the communication opponent by using a combination of a public key encryption method and a private key encryption method, and prevents tampering or interception by encrypting confidential information. In addition, this protocol not only enables authentication of the communication opponent, but also the communication origin.
Methods (technologies) using the SSL protocol and public key encryption are shown, for example, in Japanese Laid-Open Patent Application Nos. 2002-353959 and 2002-251492.
Next, a communication procedure for performing a two-way authentication using SSL is described by focusing particularly on an authentication process part. FIG. 22 is a flowchart showing processes executed by respective apparatuses in a two-way authentication using SSL, and information used in the processes.
As shown in FIG. 22, both communication apparatuses A and B employed in the two-way authentication using SSL are to be provided with a root key certificate, a private key (A,B), and a public key certificate (A,B), respectively. The private keys A, B are private keys issued to each of the communication apparatuses A, B by a certificate authority (CA). The public key certificates A, B are digital certificates provided by the CA, in which the CA attaches digital signatures to the public keys A, B corresponding to the private keys A, B, respectively. The root key certificates are digital certificates provided by the CA, in which the CA attaches digital signatures to the root keys corresponding to respective root private keys. This relation is described with reference to FIGS. 23A and 23B.
In FIG. 23A, the public key A is formed of a public key main body for decoding encoded documents using the private key A, and bibliographic information including, for example, information of the issuer of the public key A (CA) or the validity term of the public key A. In order to show that neither the public key main body nor the bibliographic information of the public key A has been tampered with, the CA performs a hash process on the public key A, and encodes the obtained hash value by using the root private key, to thereby obtain a public key certificate A having the public key A attached with a digital signature. In attaching the digital signature to the public key A, identification information of the root private key used for the digital signature is added as signature key information to the bibliographic information of the public key A.
In verifying authenticity of the public key certificate A, the digital signature included in the public key certificate A is decoded with a key main body of the root key which is a public key corresponding to the root private key. If the decoding succeeds, it is determined that the digital signature is indeed attached by the CA. If the hash value obtained by decoding with the root key main body matches with the above-described hash value obtained by hash processing the public key A, it is determined that the public key has neither been damaged nor tampered with. If it is possible to successfully decode received data with the public key A, it is determined that the data is transmitted from the holder of the private key A.
In performing the verification, it is necessary to store the root key beforehand. As shown in FIG. 23B, the root key certificate includes the root key attached with a digital signature from the CA. The root key certificate is a self signature type which allows the digital signature to be decoded with the public key included therein. In using the root key, the digital signature is decoded with the root key main body included in the root key certificate, to thereby compare the hash value obtained by decoding with the root key, and the hash value obtained by hash processing the root key. If the hash values match, it is determined that the root key has neither been damaged nor tampered with.
Next, FIG. 22 is described. In FIG. 22, the arrows are illustrated for indicating data transfer, in which a sender transmits data during a step that is indicated proximate to the arrow stem, and a receiver executes a step indicated proximate to the arrow head upon receiving the data. The moment any one of the steps ends in failure, a response reporting the failure is transmitted, and the authentication process is discontinued. The same applies in a case when receiving the response reporting failure, or when a timeout of a process occurs.
In the example shown in FIG. 22, a communication apparatus A requests communication (connection) to a communication apparatus B. In conducting the request, a CPU of the communication apparatus A executes a prescribed control program, and starts the process shown in the left side of the flowchart shown in FIG. 22. Then, in Step S11, the communication apparatus A transmits a connection request to the communication apparatus B.
Meanwhile, when the communication apparatus B receives the connection request, a CPU of the communication apparatus B executes a prescribed control program, and starts the process shown in the right side of the flowchart shown in FIG. 22. Then, in Step S21, the communication apparatus B generates a first random number(s) and encodes the first random number with a private key B. In Step S22, the encoded first random number and the above-described public key certificate B are transmitted to the communication apparatus A.
In Step S12, when the communication apparatus A receives the encoded first random number and the public key certificate B, the communication apparatus A determines the authenticity of the public key certificate B by using the root key certificate.
In Step S13, when the communication apparatus A determines that the public key certificate B is authentic, the communication apparatus A decodes the encoded first random number by using the public key B included in the public key certificate B. If the decoding is successful, it is determined that the first random number is indeed originating from the issue target of the public key certificate B.
In Step S14, aside from the above, the communication apparatus A generates a second random number(s) and a common key seed. The common key seed can be generated, for example, by using data handled in previous communications. In Step S15, the second random number is encoded by using the private key A, and encoding the common key seed by using the public key B. In Step S16, the encoded second random number and the encoded common key seed are transmitted to the communication apparatus B. The encoding of the common key seed prevents an apparatus of a person other than the communication opponent from accessing the common key seed.
In Step S17, a common key is generated from the common key seed generated in Step S14, after which the common key is to be used in encoding communication from thenceforth.
In Step S23, when the communication apparatus B receives the data transmitted in Step S16, the communication apparatus B determines the authenticity of the public key certificate A by using the root key certificate. In Step S24, when it is determined that the public key certificate A is authentic, the communication apparatus B decodes the second random number by using the public key A included in the public key certificate A. If the decoding is successful, it is determined that the second random number is indeed originating from the issue target of the public key certificate B.
Then, in Step S25, the communication apparatus B decodes the common key seed by using the private key B. Accordingly, the communication apparatus A and the communication apparatus B share the same common key seed. Thus, no apparatus other than the communication apparatuses A and B has access (knowledge) of the common key seed. In Step S26, when the foregoing steps are successfully completed, the communication apparatus B generates a common key, which is to be used in encoding communication from thenceforth, from the common key seed.
Subsequent to Step S17 of communication apparatus A and Step S26 of communication B, the communication apparatuses A and B confirm with each the success of the authentication process and the encoding method that is to be used in communication thenceforth. Then, the authentication process is finished. The confirmation step includes a response informing success of the authentication from the communication apparatus B. Hereafter, communication between the communication apparatus A and the communication apparatus B is established, wherein the communication is performed by encoding data with a common key encoding method.
With this authentication process, the communication apparatuses A, B can securely share a common key after verifying each other's authenticity, and thereby establish a secure communication route.
In the above-described authentication process, however, the step of encoding the second random number by using the public key A (Step S15 in FIG. 22) and the step of transmitting the public key certificate A (Step S16 in FIG. 22) are not requisites. In this case, the communication apparatus B does not perform the Steps S23 and S24 shown in FIG. 22, but alternatively performs a process shown in FIG. 24. Here, although the communication apparatus B is unable to verify authenticity of the communication apparatus A, this is sufficient in a case where only the communication apparatus A needs to verify the communication apparatus B. In this case, only the root key certificate is required to be stored in the communication apparatus A, and neither the private key A nor the public key certificate A are required to be stored therein. The root key certificate is not required to be stored in the communication apparatus B.
In the above-described authentication processes, data encoded with a public key can only be decoded with a private key corresponding to the public key, and data encoded with a private key can only be decoded with a public key corresponding to the private key. Accordingly, one can determine that its communication opponent is the apparatus indicated as the issue target in the public key certificate (or the user of the apparatus indicated as the issue target in the public key certificate).
Under the premise that the secrecy of the route private key of the CA is ensured, one can determine that the public key certificate has been authenticated by the CA, and that the CA has ensured the correctness of content of the public key certificate. However, there is no way other than trusting the authentication of the CA in terms of whether the communication opponent is indeed the one indicated in the public key certificate. Therefore, credibility of the CA is an important factor for ensuring security in communication by using public key authentication.
Meanwhile, companies such as VeriSign Inc. or Baltimore Technologies serve as third-party organizations providing a commercial service of verifying owners of private keys, providing digital signatures to public keys corresponding to the private keys, and issuing public key certificates. Public key certificates that are widely used are those issued by highly trusted third-party organizations having a public key issuing system that strictly controls private keys and the like. Furthermore, in authentication using digital certificates, there is a demand to use public key certificates that are issued by the highly trusted third-party organizations.
In addition, route keys used in determining the content of digital signatures from highly trusted third-party organizations are often installed in a commonly used Web browser (e.g. Internet Explorer (Registered Trademark), Netscape (Registered Trademark)) beforehand. Therefore, the user of such a Web browser acquires a benefit of not having to obtain a new route key or set the obtained route key.
Even if the route key is not pre-installed in the user's terminal apparatus, it is more likely that the user would agree in setting the route key if the route key is that of a highly trusted third-person organization. Furthermore, by obtaining the route key, apparatuses having a public key certificate issued by the same third-party organization can perform authentication regardless of the manufacturer or vendor of the apparatus. Therefore, use of a public key certificate issued by a third-party organization is effective in connecting to an apparatus of a different manufacturer, and is in large demand not only by manufacturers of the communication apparatuses but also the users of the communication apparatuses.
In order to improve credibility of the public key certificates, the third-party organizations set a validity term to its issued public key certificates. Although the public key certificates are typically set with a term of several years, some public key certificates are set with a short term ranging from 1 to 3 years. In an authentication process, a public key certificate having an expired validity term is considered as an invalid public key certificate.
Expiration of the validity of the public key certificate may not be a significant problem in a case where a user can easily renew the validity term of the public key certificate by using another apparatus (e.g. personal computer). However, dealing with the expiration of the validity term of a public key certificate could become an obstacle, for example, in a case where renewal is difficult due to skill or environment of the user, or a case where it is inappropriate to allow the user to freely renew (set) the public key certificate.
More specifically, for example, in a case where the validity term expires due to an apparatus being switched off during the expiration of the validity term, the public key certificate can no longer be used in authentication, thereby raising a problem in that a new public key certificate cannot be reliably nor easily obtained. This problem may also occur in a case of an apparatus having a preinstalled public key certificate, in which the apparatus remains unshipped in a warehouse until the expiration of the validity term.
This problem could occur even in a case where a vendor or manufacturer issues a public key certificate to an apparatus, especially when a validity term is shortened for security purposes, and could occur in a case where a digital certificate other than the public key certificate is used.